A Compositional Framework for Service Interaction Patterns and Interaction Flows

We provide precise high-level models for eight fundamental service interaction patterns, together with schemes for their composition into complex service-based business process interconnections and interaction ows, supporting software-engineered business process management in multi-party collaborative environments. The mathematical nature of our models provides a basis for a rigorous execution-platform-independent analysis, in particular for benchmarking web services functionality. The models can also serve as accurate standard speci cations, subject to further design leading by stepwise re nement to implementations. We begin by de ning succinct rigorous models to mathematically capture the behavioral meaning of four basic bilateral business process interaction patterns (Sect. 1), together with their re nements to four basic multilateral interaction patterns (Sect. 2). We then illustrate with characteristic examples how by appropriate combinations and re nements of these eight fundamental patterns one can de ne arbitrarily complex interaction patterns of distributed service-based business processes that go beyond simple request-response sequences and may involve a dynamically evolving number of participants. This leads to a de nition of the concept of process interaction ow or conversation, namely via multi-agent distributed interaction pattern runs (Sect. 3). We point to various examples in the literature on web-service-oriented business process management, which illustrate the models and concepts de ned here. We start from the informal business process interaction pattern descriptions in [2]1, streamlining, generalizing or unifying them where the formalization suggested to do so. Our models provide for them an accurate high-level view one can consider as ground model (blueprint) de nition, in the sense de ned in [4], clarifying open issues and apt to direct the further detailing, by stepwise re nement in the sense de ned in [5], to an executable version as for example BPEL code. Since for the semantics of the forthcoming BPEL standard a formal model has been provided in [15,24,13,14], such re nements can be mathematically investigated to prove their correctness with respect to the ground model, thus preparing for the application of verifying compiler techniques [17,10]. For the modeling we use the Abstract State Machines (ASMs) method with its ASM ground model and ASM re nement techniques, extending the pattern description scheme outlined in [8,9]. The support the ASM notion o ers to express the dynamics of abstract state changes allows us to provide a high-level state-based view of service inter-action patterns, where the behavioral interface is de ned through pattern actions performed by submachines, which remain largely abstract due to the intention to leave the design space open for further re nements to concrete pattern instantiations. Most of what we use below to model service interaction patterns by ASMs is selfexplanatory, given the semantically well-founded pseudo-code character of ASMs, an extension of Finite State Machines (FSMs) by a general notion of state. For the sake of completeness we sketch in the appendix (Section 5) what is needed for a correct understanding: the simple semantics of ASMs as extension of FSMs by generalized memory locations together with the ASM classi cation of locations and functions that supports modularity in high-level system descriptions. A recent tutorial introduction into the ASM method for high-level system design and analysis is available in [7]. For a more detailed textbook presentation of the method see the AsmBook [12]. 1 All the not furthermore quali ed quotes in this paper are from there. 1 Basic components of bilateral interaction patterns The basic bilateral (one-to-one) interaction patterns we have identi ed are characterized by four component type ASMs, re nements of which su ce to compose any other bilateral interaction pattern of whatever structural complexity: Send and Receive and their sequential combinations SendReceive (for sending a request followed by receiving a response) and ReceiveSend (for receiving a request followed by sending a response). Each of these pattern components describes one side of an interaction, as illustrated in Figure 1, so that all the basic bilateral interaction pattern ASMs we de ne in this section are mono-agent machines or modules. Fig. 1. Basic Bilateral Interaction Pattern Types 1.1 Pattern Send Di erent versions for sending are considered, depending on whether the delivery is reliable (guaranteed) or not and whether, in case of reliable delivery, the action is blocking or non-blocking. Also the possibility is contemplated that the send action may result in a fault message in response or that a periodic resending of a message is performed. For each version it is required that the counter-party may or may not be known at design time. This is re ected by the following possibly dynamic function, associating a recipient to each message. In case the recipient depends on further parameters, one has to re ne recipient(m) by adding those parameters to the function to determine recipient(m; param). recipient :Message ! Recipient recipient :Message Param ! Recipient All considered types of the send pattern use an abstract machine BasicSend(m) with the intended interpretation that message m is sent to recipient(m), or to recipient(m; param) in case some additional recipient parameters are given by the context. Some patterns also use the notation BasicSend(m; r) where r = recipient(m; param). This abstraction will be re ned below, e.g. to capture broadcasting instead of bilateral sending. It also re ects that the underlying message delivery system is deliberately left unspeci ed. To indicate that a faulty behavior has happened at the receiver's side as result of sending message m, we use an abstract monitored predicate Faulty(m) with the intended interpretation that a fault message in response has arrived. Possible faults originating at the sender's side, during an attempt to send a message m, are captured by a SendFaultHandler, typically triggered by a condition not OkSend(m). A typical re nement of OkSend(m) would be that there exists a channel, connecting the sender to the recipient, which is open to send m. We therefore have two abstract methods, a machine which does a FirstSend(m) without further resending and a machine to HandleSendFault(m). These two machines use, as guards for being triggered, abstract monitored predicates SendMode(m) respectively SendFaultMode(m). A typical assumption on the underlying scheduler for calling these machines will be that for each m, SendFaultMode(m) can become true only after SendMode(m) has been true. To formalize sending messages whose delivery is requested to be guaranteed by an acknowledgement, a machine SetWaitCondition will typically Initialize a shared predicateWaitingFor(m), whose role is to record that the sender is still waiting for an acknowledgement which informs that m has been delivered. In case of a BlockingSend(m), the blocking e ect is formalized by setting status := blocked(m). Here status itself is not parameterized by m given that its role is to possibly block the Send machine from further sending out other messages (see below the discussion of the blocking case). FirstSend(m) = if SendMode(m) then 2 if OkSend(m) then BasicSend(m) if AckRequested(m) then SetWaitCondition(m) if BlockingSend(m) then status := blocked(m) HandleSendFault(m) = if SendFaultMode(m) then SendFaultHandler(m)3 As typical assumption SendMode(m) and not OkSend(m) implies SendFaultMode(m) = true. Send&Check = fFirstSend(m);HandleSendFault(m)g4 Send Without Guaranteed Delivery. For the instantiation of Send&Check to SendnoAck it su ces to require AckRequested and BlockingSend to be always false. MODULE SendnoAck = Send&Check where 5 forall m AckRequested(m) = BlockingSend(m) = false Guaranteed Non-Blocking Send. For the instantiation of Send&Check to SendackNonBlocking with guaranteed delivery, but without blocking e ect, it su ces to require AckRequested to be always true resp. BlockingSend to be always false and to further detail the abstract submachine SetWaitCondition(m). This machine has to Set various deadlines and to Initialize the predicate WaitingFor(m),6 which is reset to false typically through an action of the recipient(m) upon receipt of m, e.g. by sending an acknowledgement message under a reliable messaging protocol7. Among the various deadlines occurring in di erent patterns we mention here deadline(m) and sendTime(m), which are typically used to de ne Timeout(m) by (now sendTime(m) > deadline(m)), using a system time function now to which sendTime(m) is set in Set. We also mention a function frequency(m) which will help to de ne the frequency of events expected by the sender, e.g. the arrival of response messages or the ResendTime(m) at which m has to be resent periodically (see below). A frequent requirement on the scheduler is that SendFaultMode(m) is implied by a Timeout(m), although some patterns come with Timeout concepts which are not related to faulty message sending and therefore trigger other machines than TimeoutFaultHandlers. 2 For notational succinctness we assume the ring of this rule to be preemptive. This means that when the rule is applied because SendMode(m) became true, SendMode(m) becomes false as a result of this application. Usually such an preemptiveness assumption is automatically guaranteed through further re nement steps. 3 As for FirstSend(m) we assume also the ring of HandleSendFault(m) to be preemptive. 4 By this notation we indicate that Send&Check consists of the two methods FirstSend and HandleSendFault, callable for any legal call parameter m, whatever may be the parameter passing mechanism. 5 Notationally we use unrestricted quanti ers, assuming that their underlying range is clear from the context. 6 This predicate re ects the not furthermore speci ed message delivery system. In some cases below it will be re ned by providing further details for its de nition. 7 The limit case is possible that Initialize(WaitingFor(m)) sets WaitingFor(m) := false in case of immediate and safe delivery. MODULE SendackNonBlocking = Send&Check where forall m AckRequested(m) = true and BlockingSend(m) = false SetWaitCondition(m) = Initialize(WaitingFor(m)) Set(deadline(m); sendTime(m); frequency(m); : : :) Guaranteed Blocking Send. For the instantiation of Send&Check to SendackBlocking with guaranteed delivery and blocking e ect, we require both AckRequested and BlockingSend to be always true, re ne SendMode(m) to status = readyToSend and add a submachineUnblockSend(m). Its role is to switch back from blocked(m) to an unblocked status, typically readyToSend , and to PerformAction(m) to be taken upon the end of the waiting period.8 For a succinct formulation of the re nement of SetWaitcondition we use the following notation introduced in [6]: M addRule R denotes the parallel composition of M and R. M addRule R = MR To avoid confusion among di erent machines, which occur as submachine of machines N ;N 0 but within those machines carry the same name M , we use indexing and write MN respectively MN 0 . MODULE SendackBlocking = Send&Check [ fUnblockSend(m)g where forall m AckRequested(m) = BlockingSend(m) = true SendMode(m) = (status = readyToSend) SetWaitCondition(m) = SetWaitConditionSendackNonBlocking (m) addRule status := blocked(m) UnblockSend(m) = if UnblockMode(m) then Unblock(status) PerformAction(m) UnblockMode(m) = (status = blocked(m) and notWaitingFor(m)) SendFaultMode(m) = (Faulty(m) and status = blocked(m) andWaitingFor(m)) Send with Resending. In case one wants a still not delivered message to be resent from time to time, it su ces to periodically trigger an additional machine ReSend(m) 9 until the WaitingFor(m) value has changed to false|or a Faulty(m) event triggersHandleSendFault(m), which typically is assumed to stop ReSending. We write the pattern for any SendType considered above, namely t 2 fnoAck ; ackNonBlocking ; ackBlockingg. We foresee that message copies are variations newVersion(m;now) of the original m, where the variation may depend on the current time now . MODULE SendtResend = Sendt [ fReSend(m)g where ReSend(m) = if ResendMode(m) then BasicSend(newVersion(m;now)) lastSendTime(m) := now ResendMode(m) = ResendTime(m) andWaitingFor(m) 8 We use here an abstract machine Unblock(status) instead of status := readyToSend to be prepared for further re nements of PerformAction which could include status updates, in coordination with a corresponding re nement of Unblock(status). 9 The period is determined by a predicate ResendTime(m), which typically is de ned in terms of the function lastSendTime(m) and the monitored system time now . For a pictorial representation of SendackBlockingResend see Figure 2. It generalizes the Alternating Bit Sender control state ASM diagram in [p.243][12]. Fig. 2. Blocking Send with Acknowledgement and Resend We reassume here the de nition of the set of SendTypes considered in this paper: SendType = fnoAck ; ackNonBlocking ; ackBlockingg [fnoAckResend ; ackNonBlockingResend ; ackBlockingResendg 1.2 Pattern Receive We formalize a general form for receiving messages, which can be instantiated to the di erent versions discussed in [2], depending on whether the action is blocking or non-blocking, whether messages which upon arrival cannot be received are bu ered for further consumption or discarded and whether an acknowledgement is required or not. Also the possibility is contemplated that the receive action may result in a fault message. For each version it is required that the party from which the message will be received may or may not be known at design time. This is re ected by the following possibly dynamic function, associating a sender to each message. sender :Message ! Sender We use abstract predicates checking whether a message m is Arriving10 and ToBeAcknowledged and whether our machine is ReadyToReceive(m) and in case it is not whether the message is ToBeDiscarded or ToBeBu ered , in which cases the action is described by abstract machines to Consume(m), Discard(m), Buffer(m) or to send an Ack(m) message or a faultMsg(m) to the sender(m). For the bu ering submachine we also forsee the possibility that upon DequeueTime, 10 The intended interpretation of Arriving(m) is that m is in the message channel or in the message bu er. which is typically de ned in terms of the enqueueTime of messages, a Dequeue action is required. We leave it as part of the here not furthermore speci ed submachines Discard(m) and Enqueue(m) to acknowledge by BasicSend(discardOrBu erMsg(m); sender(m)) a received but discarded or bu ered message m where required. Similarly one may consider sending a further acknowledgement as part of the Dequeue submachine. Receive(m) = if Arriving(m) then if ReadyToReceive(m) then Consume(m) if ToBeAcknowledged(m) then BasicSend(Ack(m); sender(m)) elseif ToBeDiscarded(m) then Discard(m) else Buffer(m) where Buffer(m) = if ToBeBu ered(m) then Enqueue(m) enqueueTime(m) := now if DequeueTime then Dequeue Remark. Note thatConsume andDiscard are typically realized at the application (e.g. BPEL) level, whereas Buffer(m) belongs to the system level and is usually realized through lower level middleware functionality. Instances of Receive(m). It is now easy to de ne special versions of Receive by restricting some of the abstract guards. Receiveblocking can be de ned as Receive where no message is discarded or bu ered, so that for an Arriving(m) that is not ReadyToReceive(m), the machine is `blocked' (read: cannot re its rule for this m) until it becomes ReadyToReceive(m), formally speaking where there is no DequeueTime and for each message m holds: ToBeDiscarded(m) = false = ToBeBu ered(m): Receivediscard can be de ned similarly as Receive where arriving messages, if they cannot be received at arrival time, are discarded, so that for each message m holds: ReadyToReceive(m) = false ) ToBeDiscarded(m) = true: Receivebu er can be de ned as Receive where arriving messages, if they cannot be received at arrival time, are bu ered, formally where for each message m holds: ReadyToReceive(m) = false ) ToBeDiscarded(m) = falseToBeBu ered(m) = true: For each of the precedingReceive instances one can de ne a versionReceiveack with acknowledgement, namely by requiring that for each message m it holds that ToBeAcknowledged(m) = true; analogously for a version ReceivenoAck without acknowledgement, where it is required that ToBeAcknowledged(m) = false holds for each message m. We reassume here the de nition of the set of ReceiveTypes considered above, where we add the distinction among those with and those without acknowledgement, depending on whether ToBeAcknowledged(m) is true or not for every m: ReceiveType = fblocking ; bu er ; discardg [ fnoAckBlocking ;noAckBu er ; ackBlocking ; ackBu erg 1.3 Pattern Send/Receive This pattern is about receiving a response to a previously sent request. One can de ne this pattern as a combination of the machines for the send and the receive pattern. The requirement of \a common item of information in the request and the response that allows these two messages to be unequivocally related to one another" is captured by two dynamic predicates11 RequestMsg and ResponseMsg with a function requestMsg , which identi es for every m 2 ResponseMsg the requestMsg(m) 2 RequestMsg to which m is the responseMsg .12 For the non-blocking version of the pattern, sending a request message is made to precede the call of Receive for the response message m by re ning the Receive-guard Arriving(m) through the condition that the message which Arrived is a ResponseMsg . If no acknowledgement of the response is requested, it su ces to require ToBeAcknowledged(m) = false for each m. Another natural assumption is that after having InitializedWaitingFor(m) through FirstSend(m), WaitingFor(m) is set at the recipient(m) to false in the moment responseMsg(m) is de ned. For the blocking version this assumption guarantees that both Receive and UnblockSend can be called for the responseMsg(m). We formulate the Send/Receive pattern for any pair (s; t) of SendType and ReceiveType. MODULE SendReceives;t = Sends [ fReceivet(m)g where Arriving(m) = Arrived(m) and m 2 ResponseMsg ResponseMsg = fm j m = responseMsg(requestMsg(m))g 1.4 Pattern Receive/Send This pattern is a dual to the Send/Receive pattern and in fact can be composed out of the same constituents, but with di erent re nements for some of the abstract predicates to let receiving a request precede sending the answer. The di erent versions of the pattern are re ected by the di erent versions for the constituent machines for the Receive or Send pattern. The re nement of SendMode(m) by adding the condition m 2 ResponseMsg guarantees that sending out an answer message is preceded by having received a corresponding request message, a condition which is represented by a predicate ReceivedMsg . MODULE ReceiveSendt;s = fReceivet(m)g [ Sends where SendMode(m) = SendModet(m) and m 2 ResponseMsg ResponseMsg = fresponseMsg(m) j ReceivedMsg(m)g An example of this bilateral service interaction pattern appears in the web service mediator model de ned in [1], namely in the pair of machines to ReceiveRequests and to SendAnswers. 2 Basic multilateral interaction patterns (Composition of basic bilateral interaction patterns) In this section four basic multi-party interaction patterns are identi ed for each of the four basic bilateral interaction pattern ASMs of the previous section, namely by allowing multiple recipients or senders: Send messages (representing requests or responses) to multiple recipients, Receive responses or requests from multiple senders, SendReceive to send requests to multiple interaction partners followed by receiving responses from them, similarly ReceiveSend to receive requests from multiple interaction partners followed by sending responses to them. 11 We identify sets with unary predicates. 12 This view of ResponseMsg can be turned into a re ned view by distinguishing at each agent ReceivedResponseMsges from ToBeSentResponseMsges. Each of these patterns describes one side of the interaction, as illustrated in Figure 3, so that all the components we de ne in this section are mono-agent ASM machines or modules. Re nements of the identi ed basic multilateral interaction pattern ASMs su ce to compose any other multilateral interaction pattern of whatever structural complexity. Fig. 3. Basic Multilateral Interaction Pattern Types 2.1 One-to-many Send Pattern This pattern describes a broadcast action where one agent sends messages to several recipients. The requirement that the number of parties to whom a message is sent may or may not be known at design time is re ected by having a dynamic set Recipient . The condition that the message contents may di er from one recipient to another can be captured by a dynamic function msgContent for \instantiating a template with data that varies from one party to another". msgContent :MsgTemplate Recipient ! Message Variations of the pattern can be captured by re ning the abstract predicates like FaultMode(m) or SendMode(m) accordingly13 and re ning the BasicSend component by forall r 2 Recipient do AtomicSendtype(m;r)(msgContent(m; r)), where the new abstract machine AtomicSend plays the role of the atomic sending mechanism for broadcasting messages to multiple recipients. We forsee that it can be of a type which depends on messages m and their recipients r . OneToManySends = Sends where BasicSend(m) = forall r 2 Recipient(m) do AtomicSendtype(m;r)(msgContent(m; r)) 2.2 One-from-many Receive Pattern This pattern describes correlating messages, received from autonomous multiple parties, into groups of given types, whose consolidation may complete successfully, e.g. into a single logical request, or trigger a failure process. \The arrival of messages needs to be timely enough for their correlation as a single logical request." The pattern can be de ned by adding to a re nement of Receive a new module GroupRules whose components manipulate groups by creating, consolidating and closing them. 13 For example SendMode(m) could be re ned for the guaranteed blocking send by stipulating SendMode(m) status = forall r 2 Recipient ReadyToSendTo(m; r) and re ning WaitingFor(m) to forall r 2 RecipientExpectedToAnswer(m) WaitingFor(m; r) or to forsome r 2 RecipientExpectedToAnswer(m) WaitingFor(m; r). The re nement of Receive consists rst of all in adapting the predicate ReadyToReceive(m) to mean that the current state is Accepting the type of arriving message. The type(m) serves to \determine which incoming messages should be grouped together". The machine Consume(m) is detailed to mean that m is accepted by and put into its current (possibly newly created) correlation group currGroup, which depends on the type(m). By the constraint that a message, to be inserted into its correlation group, has to be accepted by its currGroup, we re ect a stop condition, which is needed because in the pattern \the number of messages to be received is not necessarily known in advance". The de nition of ToBeDiscarded(m) as the negation of Accepting(m) re ects that no bu ering is foreseen in this scheme. The machine CreateGroup(type) to create a correlation group of the given type re ects that following the pattern requirements, groups can be created not only upon receipt of a rst message (namely as part of Consume), but \this can occur at any time". To InitializeGroup for a newly created element g 2 Group(t) comes up to make it the currGroup of type(g) = t , Accepting and with the timer(g) set to the current system time now . The group closure machines CloseCurrGroup and CloseGroup reset Accepting for their argument (namely currGroup or a group type) to false in case a Timeout , imposed on the correlation process, or a group completion event respectively a ClosureEvent for a correlation type does occur. To Consolidate a group g upon its completion into a single result, the two cases are forseen that the correlation \may complete successfully or not depending on the set of messages gathered" in g , wherefore we use abstract machines to ProcessSuccess(g) or ProcessFailure(g). MODULE OneFromManyReceivet = fReceivetg [GroupRules where ReadyToReceive(m) = Accepting(type(m)) Consume(m) = let t = type(m) in if Accepting(currGroup(t)) then insert m into currGroup(t) else InitInsert(m;new(Group(t))) InitInsert(m; g) = InitializeGroup(g) insert m into g ToBeDiscarded(m) = not Accepting(type(m)) GroupRules = fCreateGroup(type);Consolidate(group); CloseCurrGroup(type);CloseGroup(type)g CreateGroup(type) = if GroupCreationEvent(type) then let g = new(Group(type)) in InitializeGroup(g) InitializeGroup(g) = Accepting(g) := true currGroup(type(g)) := g timer(g) := now Consolidate(group) = if Completed(group) then if Success(group) then ProcessSuccess(group) else ProcessFailure(group) CloseCurrGroup(type) = if Timeout(currGroup(type)) or Completed(currGroup(type)) then Accepting(currGroup(type)) := false CloseGroup(type) = if ClosureEvent(type) then Accepting(type) := false This formalization permits to have at each moment more than one correlation group open, namely one currGroup per message type. It also permits to have at each moment messages of di erent types to arrive simultaneously. It assumes however that per message type at each moment only one message is arriving. If this assumption cannot be guaranteed, one has to re ne the Consume machine to consider completing a group by say m1 of m simultaneously arriving messages and to create a new group for the remaining m m1 ones (unless the completion of a group triggers the closure of the group type). 2.3 One-to-many Send/Receive Pattern This pattern is about sending a message to multiple recipients from where responses are expected within a given timeframe. Some parties may not respond at all or may not respond in time. The pattern can be composed out of the machine OneToManySend and the module OneFromManyReceive, similarly to the composition of the SendReceive modules out of Send and Receive. For this purpose the sending machine used inOneToManySend is assumed to contain the SetWaitCondition submachine to initialize sendTime(m) := now . This value is needed to determine the Accepting predicate in the module OneFromManyReceive to re ect that \responses are expected within a given timeframe". Remember that the re nement of the Receiveguard Arriving(m) guarantees that OneToManySend has been called for requestMsg(m) before OneFromManyReceive is called to Receive(m). MODULE OneToManySendReceives;t = OneToManySends [OneFromManyReceivet where Arriving(m) = Arrived(m) and m 2 ResponseMsg An instance of this multilateral service interaction pattern appears in the web service mediator model de ned in [1], realized by the machine pair FeedSendReq and ReceiveAnsw. The former is an instance of OneToManySend, the latter is used as a OneFromManyReceive until all expected answers have been received. 2.4 One-from-many Receive/Send Pattern This pattern is symmetric to OneToManySendReceive and can be similarly composed out of OneToManySend and OneFromManyReceive but with a di erent re nement, namely of the SendMode predicate, which guarantees that in any round, sent messages are responses to completed groups of received requests. Since several received messages are correlated into a single response message, which is then sent to multiple recipients, responseMsg is de ned not on received messages, but on correlation groups of such, formed by OneFromManyReceive. MODULE OneFromManyReceiveSendt;s = OneFromManyReceivet [OneToManySends where SendMode(m) = SendMode(m)s and m = responseMsg(g) for some g 2 Group with Completed(g) This pattern generalizes the abstract communication model for distributed systems proposed in [16] as a description of how communicators route messages through a network, namely by forwarding into the mailboxes of the Recipients (read: via OneToManySend) the messages found in the communicator's mailbox (read: via OneFromManyReceive). The core of this communicator model is the ASM de ned in [16, Sect.3.4], which exhibits \the common part of all message-based communication networks" and is reported to have been applied to model several distributed communication architectures. 3 Composition of basic interaction patterns In this section we illustrate how to build complex business process interaction patterns, both mono-agent (bilateral and multilateral) and asynchronous multi-agent patterns, from the eight basic interaction pattern ASMs de ned in the preceding sections. There are two ways to de ne such patterns: one approach focusses on re nements of the interaction rules to tailor them to the needs of particular interaction steps; the other approach investigates the order and timing of single interaction steps in (typically longer lasting) runs of interacting agents. To illustrate the possibilities for re nements of basic interaction pattern ASMs, which exploit the power of the general ASM re nement notion [5], we de ne two bilateral mono-agent patterns, namely an instance CompetingReceive of Receive and a re nementMultiResponse of the bilateral SendReceive. We de ne TransactionalMulticastNotification, a mono-agent multilateral instance of the multilateral OneToManySendReceive and a generalization of the well-known Master-Slave network protocol. We de ne MultiRoundOneToManySendReceive, an iterated version of OneToManySendReceive. As examples for asynchronous multi-agent patterns we de ne four patterns: Request with Referral, Request with Referral and Noti cation, Relayed Request, Dynamic Routing. The list can be extended as needed to include any complex or specialized monoagent or multiagent interaction pattern, by de ning combinations of re nements of the eight basic bilateral and multilateral interaction pattern ASMs identi ed in the preceding sections. At the end of this section we shortly discuss the investigation of interaction pattern ASM runs and link the management of such runs to the study of current thread handling disciplines. 3.1 Competing Receive Pattern This pattern describes a racing between incoming messages of various types, where exactly one among multiple received messages will be chosen for a special Continuation of the underlying process. The normal pattern action is guarded by waitingForResponses contained in expected messages of di erent types, belonging to a set Type; otherwise an abstract submachine will be called to ProcessLateResponses. The Continuation submachine is called for only one ReceivedResponse(Type), i.e. one response of some type t 2 Type, and is executed in parallel with another submachine to ProcessRemainingResponses. The interaction is closed by updating waitingForResponse to false. The choice among the competing types of received response events is expressed by a possibly dynamic and here not furthermore speci ed select ion function to select one received response of some type. An abstract machine EscalationProcedure is foreseen in case of a Timeout (which appears here as a monitored predicate). It is natural to assume that EscalationProcedure changes waitingForResponse(Type) from true to false. Apparently no bu ering is foreseen in this pattern, so that ToBeDiscarded(m) is de ned as negation of ReadyToReceive(m). An ASM with this behavior can be de ned as a re nement of Receive(m) as follows. We de ne ReadyToReceive(m) to mean that up to now waitingForResponse(Type) holds and no Timeout occurred. This notion of ReadyToReceive(m) describes a guard for executing Receive which does not depend on m. In fact we have to make CompetingReceive work independently of whether a message arrived or not, in particular upon a Timeout . Therefore also Arriving(m) has to be adapted not to depend on m, e.g. by de ning it to be always true.14 The submachine Consume is re ned to formalize the normal pattern action described above (which may be parameterized by m or not), whereas ToBeDiscarded(m) describes that either a Timeout happened or the system is not waitingForResponse(Type) any more, in which case Discard formalizes the abnormal pattern behavior invoking EscalationProcedure or ProcessLateResponses. CompetingReceive = Receive where 14 These stipulations mean that the scheduler will call CompetingReceive independently of any message parameter, which is a consequence of the above stated requirements. Arriving(m) = true ReadyToReceive(m) = waitingForResponse(Type) and not Timeout Consume = let ReceivedResponse(Type) = fr j Received(r) and Response(r ; t) forsome t 2 Typeg if ReceivedResponse(Type) 6= ; then let resp = select(ReceivedResponse(Type)) Continuation(resp) ProcessRemainingResp(ReceivedResponse(Type) n frespg) waitingForResponse(Type) := false ToBeDiscarded(m) = Timeout or not waitingForResponse(Type) Discard = if not waitingForResponse(Type) then ProcessLateResponses if Timeout then EscalationProcedure 3.2 Contingent Request This pattern has multiple interpretations. It can be de ned as an instance of SendReceive, where the Send(m) comes with the ReSend submachine to resend m (maybe to a new recipient) if no response is received from the previous recipient within a given timeframe. I can also be de ned as a combination of CompetingReceive with ReSend. In both cases the function newVersion re ects that the recipient of that version may be di erent from the recipient of the original. 3.3 Multi-response Pattern This pattern is a multi-transmission instance of the SendReceive pattern, where the requester may receive multiple responses from the recipient \until no further responses are required". It su ces to re ne the Receive-guard readyToReceive according to the requirements for what may cause that no further responses r will be accepted (and presumably discarded) for the request m, namely (a response) triggering to reset FurtherResponseExpected(m) to false or a Timeout(m) due to the expiry of either the request deadline(m) (time elapsed since the sendTime(m), set in SetWaitCondition(m) when the request m was sent) or a lastResponseDeadline(m) (time that elapsed since the last response to request message m has been received). To make this work, SetWaitCondition(m) has to be re ned by adding the initialization rule FurtherResponseExpected(m) := true. To Receive response messages m, Consume(m) has to be re ned by adding the rule lastResponseTime(requestMsg(m)) := now , so that the timeout predicate Expired(lastResponseDeadline(m)) can be de ned with the help of lastResponseTime(m). For the re nement of SetWaitCondition and Consume we use the notation M addRule R from [6] to denote the parallel composition of M and R. MODULE MultiResponses;t = SendReceives;t where SetWaitCondition(m) = SetWaitConditionSendReceives;t (m) addRule FurtherResponseExpected(m) := true ReadyToReceive(m) = FurtherResponseExpected(requestMsg(m)) and not Timeout(requestMsg(m)) Consume(m) = ConsumeSendReceives;t (m) addRule lastResponseTime(requestMsg(m)) := now ToBeDiscarded(m) = not ReadyToReceive(m) Timeout(m) = Expired(deadline(m)) or Expired(lastResponseDeadline(m)) 3.4 Transactional Multicast Noti cation This pattern generalizes the well-known Master-Slave network protocol investigated in [19,12]. In each round a noti cation m is sent to each recipient in a possibly dynamic set Recipient(m). The elements of Recipient(m) are arranged in groups, allowing in groups also further groups as members, yielding a possibly arbitrary nesting of groups. Within each group g a certain number of members, typically between a minimum acceptMin(m; g) and a maximum acceptMax (m; g) number, are expected to \accept" the requestm within a certain timeframe Timeout(m). Recipients \accept" m by sending back an AcceptMsg to the master. The pattern description given below de nes the master program in the master-slave protocol, whereas in applications it is typically assumed that each slave uses a blocking Send machine. The master ASM can be de ned as a re nement of the OneToManySendReceive pattern with blocking Send. WaitingFor(m) is re ned to not Timeout(m), so that the blocking condition status = blocked(m) appears as waiting mode for receiving AcceptMsges from Recipients in response to the noti cation m. The nested group structure is represented as a recipientTree(m) whose nodes (except the root) stand for groups or recipients. The set Leaves(recipientTree(m)) of its leaves de nes the set Recipient(m); for each tree node n which is not a leaf the set children(n) represents a group. Since for each inner node there is only one such group, we keep every corresponding currGroup(t) open by de ning it as Accepting . We can de ne type(r) = r so that currGroup(r) for any response message r collects all the AcceptMsgs which are received from brothers of sender(r). SetWaitCondition(m) is extended by a machine to InitializeMinMax(m) and a machine to InitializeCurrGroup(m) for each group. The Acceptance notion for tree nodes has to be computed by the master itself, namely as part of PerformAction(m). We abstract from the underlying tree walk algorithm by de ning Accept as a derived predicate, namely by recursion on the recipientTree(m) as follows, starting from the AcceptMsg concept of response messages accepting the noti cation m. By j X j we denote the cardinality of the set X . Accept(n), acceptMin(m; children(n)) j fc 2 children(n) j Accept(c)g j Accept(leaf ), some r 2 ResponseMsg(m) with AcceptMsg(r) was received from leaf It may happen that at Timeout(m) more than acceptMax (m; g) accepting messages did arrive. Then a \priority" function chooseAccChildren is used to choose an appropriate set of accepting children among the elements of g = children(n). The elements of all these chosen sets constitute the set chosenAccParty(root) of recipients chosen among those who accepted the noti cation m. Both functions are de ned as derived functions by a recursion on the recipientTree(m) as follows: chooseAccChildren(n) = ; if j AcceptChildren(n) j< acceptMin(m; children(n)) min;max AcceptChildren(n) else where AcceptChildren(n) = fc 2 children(n) j Accept(n)g min = acceptMin(m; children(n)) max = acceptMax (m; children(n)) A l;h B , A B and l j A j h chosenAccParty(leaf ) = fng if Accept(n) ; else chosenAccParty(n) = Sc2chooseAccChildren(n) chosenAccParty(c) The submachinePerformAction(m), which in case thatAccept(root(recipientTree(m))) holds is executed in UnblockMode(m), Processes the fullRequest(m) for the chosenAccParty at the root(recipientTree(m)), taking into account also the other recipients. Otherwise a RejectProcess is called. To formulate the re nement of SetWaitcondition we use again the notation M addRule R from [6] to denote the parallel composition of M and R. OTMSR stands as abbreviation for OneToManySendReceiveackBlocking;t . MODULE TransactionalMulticastNotifyt = OneToManySendReceiveackBlocking;t where 15 WaitingFor(m) = not Timeout(m) SetWaitCondition(m) = SetWaitconditionOTMSR(m) addRule InitializeMinMax(m) InitializeCurrGroup(m) where InitializeMinMax(m) = forall g = children(n) 2 recipientTree(m) Initialize(acceptMin(m; g); acceptMax (m; g)) InitializeCurrGroup(m) = forall r 2 Recipient(m) currGroup(r) := ; type(response) = response Accepting(response) = response 2 AcceptMsg and not Timeout(requestMsg(response)) currGroup(response) = currGroup(sender(response)) currGroup(recipient) = brothers&sisters(recipient) \ fleaf j Accept(leaf )g Accepting(currGroup(r)) = true PerformAction(m) = if Accept(root(recipientTree(m))) then let accParty = chosenAccParty(root(recipientTree(m))) others = Leaves(recipientTree(m)) n accParty in Process(fullRequest(m); accParty ; others) else RejectProcess(m) For a pictorial representation of TransactionalMulticastNotify (without arrows for the responses) see Figure 4, where the leaves are represented by circles and the groups by rectangles. Fig. 4. Transactional Multicast Notify 3.5 Multi-round One-to-many Send/ReceivePattern This pattern can be described as an iteration of (a re nement of) the OneToManySendReceive componentsOneToManySend andOneFromManyReceive. The number of one-to-many sends followed by one-from-many receives is left unspeci ed; to make it con gurable one can introduce a corresponding roundNumber counter (into the SendMode guard and the SetWaitCondition). The dynamic set Recipient guarantees that the number of parties where successive requests are sent to, and from where multiple responses to the current or any previous request may be received 15 One could probably delete the GroupRules since they are not used by this pattern. by the sender, may be bounded or unbounded. There is also no a priori bound on the number of previous requests, which are collected into a dynamic set ReqHistory . The main re nement on sending concerns the submachine SetWaitCondition, which has to be adapted to the fact that WaitingFor , sendTime and blocked may depend on both the message template m and the recipient r . Furthermore this submachine has to record the message template as new currRequest and to store the old currReq into the ReqHistory , since incoming responses may be responses to previous request versions. The pattern description speaks about responses to \the request" for each request version, so that we use the request template m to de ne currRequest (and Group types below)16. Also the guard SendMode(m) is re ned to express (in addition to the possible status condition) that forall r 2 Recipient(m) a predicate ReadyToSendTo(m; r) holds, where this predicate is intended to depend on the responses returned so far (de ned below as a derived set ResponseSoFar). The main re nement on receiving concerns the de nition of type(m) for any m 2 ResponseMsg as the requestMsg(m) that triggered the response m. This re ects that each response message is assumed to be a response to (exactly) one of the sent requests. However, every request r is allowed to trigger more than one response m from each recipient (apparently without limit), so that the function responseMsg is generalized to a relation responseMsg(m; r). Therefore currGroup(request) represents the current collection of responses received to the request . It remains to re ect the condition that \the latest response : : : overrides the latest status of the data : : : provided, although previous states are also maintained". Since the pattern description contains no further requirements on the underlying state notion, we formulate the condition by the derived set ResponseSoFar de ned below and by adding toConsume an abstract machineMaintainDataStatus to allow one to keep track of the dataStatus of previous states, for any request. OTMSR stands as abbreviation for OneToManySendReceive. MODULE MultiRoundOneToManySendReceive = OneToManySendReceive where SendMode(m) = SendMode(m)OTMSR and forall r 2 Recipient(m) ReadyToSendTo(m; r) SetWaitCondition(m) = forall r 2 Recipient(m) Initialize(WaitingFor(m; r)) sendTime(m; r) := now status := blocked(m; r) insert currRequest into ReqHistory currRequest := m type(m) = requestMsg(m) Consume(m) = Consume(m)OTMSR addRuleMaintainDataStatus(Group(requestMsg(m))) ResponseSoFar = SfGroup(m) j m 2 ReqHistoryg [ fcurrGroup(currReq)g 3.6 Request With Referral This pattern involves two agents, namely a sender of requests and a receiver from where \any follow-up response should be sent to a number of other parties : : :", in particular faults, which however \could alternatively be sent to another nominated party or in fact to the sender". Apparently sending is understood without any reliability assumption, so that the sender is simply formalized by the module SendnoAck . For referring sent requests, the appropriate version of the Receive machine is used, with the submachine Consume re ned to contain OneToManySend for the set Recipient(m) encoded as set of followUpResponseAddressees extracted from m. As stated in the requirement for the pattern, followUpResponseAddr may be split into disjoint subsets failureAddr and normalAddr . Since the follow-up response parties (read: Recipient(m)) may be 16 Otherwise one could de ne currReq(r) := msgContent(m; r) for each recipient r . chosen depending on the evaluation of certain conditions, followUpResponseAddr can be thought of as a set of pairs of form (cond ; adr) where cond enters the de nition of SendMode(m). 2-Agent ASM RequestReferral = Sender agent with module SendnoAck Referral agent with module Receive where Consume(m) = OneToManySend(Recipient(m)) Recipient(m) = followUpResponseAddr(m) For a pictorial representation of RequestReferral see Figure 5. Fig. 5. Request with Referral and Advanced Noti cation A re nement ofRequestReferral has the additional requirement of an advanced noti cation, sent by the original sender to the other parties and informing them that the request will be serviced by the original receiver. This requirement comes with the further requirement that the sender may rst send his request m to the receiver and only later inform the receiver (and the to-benoti ed other parties) about Recipient(m). These two additional requirements can be obtained by re ning in RequestReferral the SendnoAck by a machine with blocking acknowledgment| whereWaitingFor(m) means that Recipient(m) is not yet known and that Timeout(m) has not yet happened|and the PerformAction(m) submachine as a OneToManySend of the noti cation guarded by known(Recipient(m). 2-Agent ASM NotifiedRequestReferral = Sender agent with module SendackBlocking [ fOneToManySendg where WaitingFor(m) = not known(Recipient(m)) and not Timeout(m) PerformAction(m) = if not known(Recipient(m)) then SendFailure(m) else OneToManySend(advancedNotif (m)) Referral agent with module Receive where Consume(m) = OneToManySend(Recipient(m)) Recipient(m) = followUpResponseAddr(m) 3.7 Relayed Request Pattern The RelayedRequest pattern extends Request Referral by the additional requirement that the other parties continue interacting with the original sender and that the original receiver \observes a \view" of the interactions including faults" and that the interacting parties are aware of this \view". To capture this we re ne RequestReferral by equipping the sender also with a machine to Receive messages from third parties and by introducing a set Server of third party agents, each of with is equipped with two machines Receive and Send&Audit where the latter is a re nement of Send by the required observer mechanism. For a pictorial representation of RelayedRequest see Figure 6. Fig. 6. Relayed Request n+2-Agent ASM RelayedRequest = 2-Agent ASM RequestReferral where module(Sender) = moduleRequestReferral(Sender) [ fReceiveg n Server agents with module fReceive;Send&Auditg where Send&Audit = Sends with BasicSend = BasicSends [ fif AuditCondition(m) then BasicSends( ltered(m))g Using as subcomponent NotifiedRequestReferral yields NotifiedRelayedRequest. 3.8 Dynamic Routing This pattern comes with a dynamic set of agents: a rst party which \sends out requests to other parties" (an instance of OneToManySend) but with the additional requirement that \these parties receive the request in a certain order encoded in the request. When a party nishes processing its part of the overall request, it sends it to a number of other parties depending on the \routing slip" attached or contained in the request. This routing slip can incorporate dynamic conditions based on data contained in the original request or obtained in one of the \intermediate steps"." In this way the third parties become additional pattern agents to receive requests, process them and forward them to the next set of recipients. Furthermore, this set of agents is dynamic: \The set of parties through which the request should circulate might not be known in advance. Moreover, these parties may not know each other at design/build time." We therefore have a rst sender agent with module OneToManySend concerning its set Recipient(sender). We then have a dynamic set of RoutingAgents which can Receive request messages m with routingSlip(m) and Consume requests by rst Processing them and then forwarding a furtherRequest(m; currState(router)), which may depend not only on the received (and thereby without loss of generality of the original) request message, but also on data in the router state currState(router) after message processing. Thus also the routingSlip(m; currState(router)) may depend on the original request and router data. The Recipient set depends on the router agent and on the routingSlip information. For the intrinsically sequential behavior we make use of the seq operator de ned for ASMs in [11] (see also [12]). Multi-Agent ASM DynamicRouting = Agent sender with module OneToManySend(Recipient(sender)) Agents router 2 RouterAgent each with module Receive where Consume(m) = Process(m) seq OneToManySend(furtherRequest(m; currState(router))) (Recipient(router ; routingSlip(m; currState(router)))) 3.9 De ning Interaction Flows (Conversations) In the preceding section the focus for the composition of basic interaction patterns into more complex ones was on combination and re nement of basic interaction pattern ASMs, i.e. on how the interaction rules (read: the programs) executed by the communicating agents can be adapted to the patterns under consideration. An equally important di erent view of interaction patterns is focussed instead on the run scenarios, that is to say on when and in which order the participating agents perform interaction steps by applying their interaction rules. This view is particularly important for the study of interaction structures which occur in long running processes, whose collaborations involve complex combinations of basic bilateral or multilateral interaction pattern ASM moves. As an example for an interaction structure in a long running process consider a one-to-manysend-receive to short-list candidate service providers, which may be followed by a transactional multi-cast to issue service requests to selected providers, where nally individual providers may use relayed requests for outsourcing the work. An elementary example is the well-known coroutining pattern, which is characterized by two agents a1 and a2 each equipped with a SendnoAck and a Receive module. The typical scenario is a distributed run where an application of SendnoAck by a1 precedes ring Receive by a2, which (as consequence of the execution of Consume at a2) is followed by an application of SendnoAck by a2 and eventually triggers an execution of Receive at a1. Such interactions structures resemble conversations or interaction ows between collaborating parties. This concept is captured by the notion of asynchronous runs of multi-agent service interaction pattern ASMs, i.e. ASMs whose rules consist of some of the basic or composed service interaction pattern ASMs de ned in the preceding sections. Such runs, also called distributed runs, are partial orders of moves of the participating agents, each of which is (read: executes) a sequential ASM, constrained by a natural condition which guarantees that independent moves can be put into an arbitrary execution order without changing the semantical e ect. 17 We therefore de ne a conversation or interaction ow to be a run of an asynchronous service interaction pattern ASM, where such an ASM is formally de ned by a set of agents each of which is equipped with some (basic or complex, bilateral or multilateral) service interaction pattern modules de ned in the previous sections. A theory of such interaction ow patterns is needed, which builds upon the knowledge of classical work ow analysis [25]. A satisfactory theory should also provide possibilities to study the e ect of allowing some agents to Start or Suspend or Resume or Stop such collaborations (or parts of them), the e ect such conversation management actions have for example on security policies, etc. This naturally leads to investigate the impact of current thread handling methods (see for example [26,23,22]) on business process interaction management. 4 Conclusion and Outlook We would like to see the ASM models provided here (or modi ed versions thereof) be implemented in a provably correct way, e.g. by BPEL programs, and be used as benchmarks for existing implementations. We would also like to see other interaction patterns be de ned as combinations of re nements of the eight basic bilateral and multilateral service interaction pattern ASMs de ned here. In particular we suggest the study of conversation patterns (business process interaction ows), viewed as runs of asynchronous multi-agent interaction pattern ASMs. 5 Appendix: The Ingredients of the ASM Method The ASM method for high-level system design and analysis (see the AsmBook [12]) comes with a simple mathematical foundation for its three constituents: the notion of ASM, the concept of ASM ground model and the notion of ASM re nement. For an understanding of this paper only 17 Details on this de nition of partial order ASM run can be found in [12, pg.208]. the concept of ASM and that of ASM re nement have to be grasped,18 whose de nitions support the intuitive understanding of the involved concepts. We use here the de nitions rst presented in [7,3] and [5]. 5.1 ASMs = FSMs with arbitrary locations